So, the problem with this is that it breaks backward compatibility. Everyone who was using this macro will now have to use the trait to get at the generated method.

I'm also unconvinced that this is useful. Under what situations do you need the ability to pass multiple enum types to generic code so that it can iterate over the variant names, but nothing else?

Under what situations do you need the ability to pass multiple enum types to generic code so that it can iterate over the variant names, but nothing else?

Of course, it's not very useful on its own. But combined with EnumDisplay and EnumFromStr you can build a wrapper that can access and modify an enum property as strings generically, without ever knowing the concrete enum type.

Or a little less abstract: I'm experimenting with generic configuration interfaces. To configure enum settings, I need to display the current value, list available options and finally parse it back to the enum type.

I'm not sure what the standard workarounds for this kind of backwards compatibility issue are. I guess you would have both the free function and the trait and one calls the other but I'm not 100% sure so I didn't do it since I didn't need it for my usecase. In other words: Think of this PR as a suggestion, not a polished solution.